前面介紹的RAG基礎技術(稠密嵌入、稀疏嵌入、混合檢索)解決了"給定一個文本塊，如何快速找到最相關的那幾個"。

但一個更根本的問題是：這些文本塊本身該怎麼組織? 把文件切成不關聯的扁平文本塊，會丟掉知識固有的內在層次和跨文件關聯; 面對技術手冊、法律文書或學術論文這類結構複雜、邏輯嚴謹的材料，只檢索零散片段，就如同靠閱讀字典的隨機詞條去理解一部小說。

要讓Agent真正理解一個知識領域，就必須超越扁平文本塊，建構能反映知識層次與關連的結構化索引。
先講這些更高級的組織方法，然後 -- 這是關鍵的一步-- 把它們反過來應用"用戶記憶上"，解決用戶記憶檢索中的精度問題。

接下來一次討論6個主題 --它們並非一條遞進的階梯，而是圍繞"如何組織與檢索知識"從不同側面展開：
首先是兩種結構化索引 技術(RAPTOR/GraphRAG)，它們解決"如何組織知識"的問題; 然後是OpenViking的文件系統範例，展示一種輕量級的知識管理思路; 接著討論知識應該如何更新，區分即時吸收新證據的增量更新與定期重審全庫的全量整理; 再進入智能體化RAG，讓Agent自主決定檢索策略; 之後討論上下文感知檢索 --它並非加在智能體化RAG上的更高一層，而是回頭修補最基礎的分塊環節，提升每個分塊自身的檢索品質; 最後展示如何從結構化數據集中，提取深度知識。

還有個問題：即使建好RAG，若只把大量原始案例平鋪進知識庫，檢索也無法保證召回全部相關訊息，模型於是基於不完整的上下文做出錯誤判斷。以下兩個舉例：

EX1.黑貓白貓的計數問題："注意力是軟檢索"，即使100個案例全部裝進上下文窗口，模型也難以完成精確計數。在使用RAG的情況下，問題會更嚴重。假設知識庫有100個獨立案例文件(90隻黑貓、10隻白貓，每個都是獨立文本塊)，用戶詢問"比例是多少?"時，受限於TOP-K(Ex.20)，大部分案例根本不會被檢索到。模型只能基於不完整樣本(比如只看到15隻黑貓與3隻白貓)得出錯誤結論。

EX2.Xfinity優惠資格的邊界問題：這次的知識庫是客服工單歸檔，幾百條供單各自紀錄一次真實的處理結果：退伍軍人John通過審核，醫生Sarah拿到折扣，教師Mike被告知不符合條件..每條工單只寫清一個個案的結論，沒有任何一條寫著資格範圍本身。護士來問"我能不能享受優惠"時，同樣有幾重障礙：
首先是最近鄰偏置--"護士"與"醫生"語意最近，Sarah那條牌最前面，模型順是推斷護士也可以; 若Mike那條碰巧排得更前面，同一個問題就會得到相反的答案。
其次是邊界語意的缺失--這一重障礙調大K也解決不了："僅限....，其他一慮不適用"這種帶全稱與否定的邊界，不存在於任何單條工單中。
最後是完整性信號缺失--模型無從判斷自己是否已經看完，於是不會追問，只照著手上這幾條自信作答。

解決辦法仍要從檢索階段入手：離線通讀整個工單庫、提煉出一條規則卡"Xfinity優惠適用於現役與退伍軍人、持證醫護人員(含護士); 教師等其他職業不適用"。

兩個案例指向同一個結論：把原始案例或文件不加處理的直接放進知識庫是遠遠不夠的。無論是存入向量數據庫、檢索後注入上下文，還是直接塞進上下文，未經提煉和結構化的知識，模型都無法可靠的利用。
因此必須再索引階段投入計算資源，對原始知識主動提煉、抽象與結構化-- 把"100個個體案例"壓縮為統計摘要，把"散落在幾百條工單裡的個案"提煉為帶邊界的明確規則。

遊戲開發進入 Agent 時代！OpenAI 與 Unity 官方聯手：Codex 正式推出 Unity 官方插件，31 大原生引擎 Skills、MCP 即時除錯與全新工作流深度解析
https://www.aiposthub.com/openai-codex-unity-plugin-deep-dive-2026/